Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Wei-Yu

#34919 sí, ese es el problema.

MTX_Anubis

#34918 Hay locks a nivel de rows. Un select for update te lockea solo las rows válidas (si cumple ciertas condiciones vaya). La optra opción es un optimistic locking.

Todo esto a nivel de DB, a nivel de aplicación tienes entre locks como evitar acceso concurrente (solo el scheduler asigna pedidos y solo lo hace de uno en uno).

1 respuesta
Wei-Yu

#34922 el row lock lo pensé pero no recuerdo dónde vi un problema con ello, supongo que como la pregunta era muy vaga (por motivos evidentes) si asumes que vas a leer todos los datos el resultado puede ser similar a un table lock para el worst case, pero claro tienen que cumpirse muchas condiciones algo raras para llegar ahí xd

1 respuesta
Troyer

Un mutex de toda la vida vamos.

2 1 respuesta
desu

Mira el lado bueno, si no pasas ni la tecnica no te echan en la cultural.

#34924 Entiendo que el Mutex es la respuesta mala. Porque no necesitas exclusivdad de read y write. Solo write.

De hecho estoy casi seguro que lo puedes hacer lock-free sin usar nada de syncronizacion.

Suponiendo que tu escribas el servicio y no sea solo "patchear" el problema, que entonces entiendo que seria un mutex o un rwlock segun como este implementado.

1 respuesta
MTX_Anubis

#34923 Para mi estos casos lo mejor es un optimistic locking, evitas potenciales locks aunque depende del caso puedes llegar a tener muchas colisiones (aquí los locks tampoco te salvarían porque perderías toda la concurrencia posible)

así que tendrías que comenzar a plantearlo de otra forma

1
Wei-Yu
#34925desu:

De hecho estoy casi seguro que lo puedes hacer lock-free sin usar nada de syncronizacion.

desarrolla por aquí

El mutex yo lo descarté, fue lo primero que pensé pero no le encontré mucho sentido una vez pensé algo más. Lo de optimistic locking npi voy a echarle un ojo.

2 respuestas
desu

#34927 hombre el mutex es lo primero que tienes que poner XD lo que tienes que saber es que tipo de mutex necesitas.

1 lectura - 1 escritura
N lecturas - 1 escritura
1 lectura - N escrituras
N lecturas - N escrituras

si cada repartidor solo se encarga de una zona concreta, tienes un sharding o una cola... no tienes ningun problema ahi XD

puedes tener buckets de repartidores segun si capacidad, que cuando haces free los pones en una pila. si te entra algo de 10 de capacidad, vas a la pila que sea >10 y pillas al primero disponible. ahi solo te tienes que preocupar por no coger 2 repartidores del mismo bucket.

pero aun podemos quitar mas cosas, si pueden entrar capacidades de 1 a 10, tienes 10 buckets... y distribuyes a tus repartidores de tal forma que tengan 1,2,3,...10 de capacidad fija. a cada bucket, un par de repartidores. ahora ya ni siquiera necesitas sincronizar... tienes colas perfectamente distribuidas y paralelizadas... si llega un pedido de capacidad 5 y no hay nadie, cuando llegue un repartidor de 5 lo hara.

suponiendo que el trafico es equitativo no hay ningun problema en hacer esto. todo depende de tu problema. en fin. que pon un mutex siempre y luego mira el algoritmo.

2
MTX_Anubis

#34927 el optimistic locking al final es comprobar que se puede hacer el update. Cuando vas a guardarlo meter las condiciones

where menId = <id> and version = <version_leida> 
o esta
where menId = <id> and capacidad >= 25

Y con el transaction isolation correcto

Y después compruebas si te ha devuelto row actualizada.

Como te digo esto pude generar muchas colisiones

1 1 respuesta
desu

#34929 https://docs.rs/bumpalo/latest/bumpalo/

busca por google: bump allocator, bucket allocator, fixed size buckets allocator...

haces "free" metiendo memoria al final cuando te vuelve un worker...

en el caso perfecto el bucket = minima granularidad de capacidad, si esto no es posible gasta memoria (capacidad desaprovechada por worker) haciendo buckets mas grandes. el trade off es, cual es tu bottle neck? la memoria (capacidad) o los workers (threads)?

al final te sale un problema de colas como he puesto arriba pero no tienes colisiones como en tu caso. lo que tu quieres en vocabulario db es sharding de algun tipo.

2
r2d2rigo

Bueno, cuando invitais a pimpollo a este hilo.

_Rpv

Ese picaba en .net, no?

1 respuesta
Sphere

Hostia el pimpollo unchained en el hilo de los salarios xDDDDD

Como se nota que le pica joder, pero bueno, haber estudiao. Aprender a programar es de lo más accesible que existe a día de hoy pero requiere esfuerzo y constancia.

r2d2rigo

#34932 no lo se pero donde deberia estar picando es en una mina.

3
Wei-Yu

Muy buena, desu.

Qué envidia verte con 2 años de exp con ese bagaje. Te mereces los 80k + stocks.

1 respuesta
desu

#34935 no tengo ni 80k ni stocks

lo que si tengo es un trozo de carne que te puedes meter por el culo vegano apestoso

15
aren-pulid0

Demostrando quien no es un fpero

1 respuesta
desu

#34937 es mas puedes tener un scheduling work stealing que es la estrategia mas habitual y eficiente hoy en dia

imagina que tienes 4 colas de trabajo, ordenadas de menos a mas capacidad necesaria, te van entrando pedidos de trabajo y tu los vas asignando a la cola minima disponible, si en algun momento alguna cola tiene muchos trabajadores parados, coges de una cola inferior (que tambien puedes completar).

de esta manera se resuelve normlamente el problema de tener un thread idle...

te dire mas, si tu alocas para ejecutar un worker con capacidad 20, y completas 10, quien te dice que no puedes volver a poner estos 10 faltantes a la cola y liberar al worker???

[00-05] con 4 workers
[05-10] con 4 workers
[15-20] con 4 workers
[20-25] con 4 workers

Entra una tarea de capacidad 10 a la cola 2

[00-05] con 4 workers
[05-10] con 3 workers, 1 running worker 10
[15-20] con 4 workers
[20-25] con 4 workers

cuando llega a 5 haces split

[00-05] con 2 workers, 2 running worker con 5
[05-10] con 4 workers
[15-20] con 4 workers
[20-25] con 4 workers

o dejas 1 en cada cola, depende de si quieres ir equilibrando o no. ahi solo pagas el coste de crear una nueva sub task y el "job stealing".

el ejemplo anterior:

[00-05] con 4 workers
[05-10] con 4 workers
[15-20] con 4 workers
[20-25] con 4 workers

entra 5 de capacidad 18, no tenemos 5 workers en el bucket [15-20], asi que podemos pillaruno de arriba.

[00-05] con 4 workers
[05-10] con 4 workers
[15-20] con 0 workers, 4 trabajando con 18
[20-25] con 3 workers, 1 trabajando con 18

edit 25:

https://www.arnaudiaz.com/blog/what-should-a-beginner-learn/

posteado el 2021-10-26, seguramente foreado meses o a;os antes, a ver si espabilan estos fperos

mucho jiji jaja cuando puse los items, ahora resulta que no saben ni lo que es un mutex ni un scheduler basico

Kaledros

¿Qué podemos ofrecerte?

  • Teletrabajo 100%
  • Jornada intensiva los meses de Julio y Agosto con flexibilidad horaria.
  • Además, dos días de jornada intensiva a la semana los meses de Septiembre a Junio y siempre flexibilidad horaria

Que alguien me explique cómo puedes tener jornada intensiva con flexibilidad horaria, por favor.

1 respuesta
Fyn4r

#34939 Es que "flexibilidad horaria" suele significar que puedes llegar tarde

1 1 respuesta
Kaledros

#34940 Ya, como cuando te dicen que tienes flexibilidad horaria pero el core time son seis horas al día.

1 1 respuesta
Fyn4r

#34941 Yo una vez escuché la frase "debemos ser estrictos en la flexibilidad", que básicamente era que si ibas por la mañana a la oficina por cualquier razón debías quedarte allí el resto del día xD

1 2 respuestas
Kaledros

#34942 Ole, ole y ole XDDDD

pineda

#34942 yo tuve uno de esos, de empresa modernita con horario flexible. Únicamente te exigian estar en la oficina a las 9-9.30 , y que no te fueses antes de las 5 de la tarde. Pero flexible

1
fehnd

Donde yo trabajo tenemos que hacer las horas entre las 6 de la mañana y las 9 de la noche, parando cuando queramos y las veces que queramos, y la intensiva es lo mismo pero quitando una horilla de curro xD

JuAn4k4

A nosotros nos ponen horario de 36h en verano pero nos obligan a que sea el Viernes, que no trabaja ni el apuntador, ya que no hay reuniones. Tenemos ya jornada de 4d a la semana, salvo que haya algún incidente grave.

desu

que hago?

NSFW que borrare en un rato

1 respuesta
newfag

Buenos días lo primero desu

1 respuesta
desu

#34948 Es que me jode cuando me toca hacer PR duras.

No quiero hacerlas sabes?

Si por mi fuera todo aprovado.

Pero no soy un fpero.

1 respuesta
newfag

#34949 desu, se te perdona el narcisismo, la soberbia, el no dar los buenos días, pero que escribas aprovado no

Usuarios habituales